Controller helpers #56
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hiddeco
reviewed
Nov 26, 2020
seaneagan
reviewed
Dec 4, 2020
|
@hiddeco, @seaneagan: is this useful enough to be worth persevering, wdyt? |
|
I think that with our comments addressed it would be really useful to get good Kubernetes events and metadata rich notifications. So, yes! |
hiddeco
force-pushed
the
controller-shell
branch
2 times, most recently
from
a21e69c to
2144df2
Compare
hiddeco
force-pushed
the
controller-shell
branch
2 times, most recently
from
408ae15 to
5eaace5
Compare
squaremo
commented
May 12, 2021
This adds a struct which can be embedded in a reconciler, which contains the metrics recording logic. Signed-off-by: Michael Bridgen <michael@weave.works>
This adds the capability of sending events to Kubernetes and the notification controller. Signed-off-by: Michael Bridgen <michael@weave.works>
This commit adds support for providing a reason to the Event method, and maps the severity of an event to a K8s core event type. This makes the emitted events in-line with Kubernetes standards, and is beneficial to the Flux UI: fluxcd/webui#13 The reason to not fully depend on the K8s event type and drop the severity is because there have been reports from users wanting to have access to "debug" events, a type not known to Kubernetes. Signed-off-by: Hidde Beydals <hello@hidde.co>
To allow recording metrics for conditions other than just the readiness status. The `RecordReadinessMetric` method is kept in place for API consumption convenience. Signed-off-by: Hidde Beydals <hello@hidde.co>
This commit addresses the two rough edges mentioned by Michael. > You have to supply an ObjectReference to both the metrics and the > events methods. As the helper methods are always called from within a reconciler, and both events and metrics must only be recorderd for well known resources, the methods of the helpers should only be called for objects that do contain data about the kind and/or version. This means that calling `reference.GetReference` within the helper methods will generally not result in any errors, nor be a really expensive calculation. In cases where the GVK information for some reason is not available on the object, `GetReference` will still be capable of falling back to the manager's `runtime.Scheme` that is now injected to the helper. Resulting in a - in my personal opinion - fair trade-off, and a much more friendly API from the consumer's perspective. > You have to pass logs in to the Events helper. By relying on the context of the reconcile operation we get a logger (with object metadata preconfigured) for free. Signed-off-by: Hidde Beydals <hello@hidde.co>
Signed-off-by: Hidde Beydals <hello@hidde.co>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an experimental PR to see if some of the bits common to all the GOTK controllers can be factored out into embeddable structs.
Among other things, this will
It is a bit rough around the edges:
You have to supply an ObjectReference to both the metrics and the events methods. This is because all the constituent bits calculated this for themselves, and had different ways of dealing with errors. This way, the error handling is done once, up front, and the ref only has to be calculated once. But it would be nice to do this behind the scenes, in some way.
You have to pass logs in to the Events helper. This is a bit awkward, as getting logs to funcs always is. It'd be nice if the setup could just do this for you.